Matthias Clasen [Thu, 11 May 2023 00:19:23 +0000 (20:19 -0400)]
gtk: Don't drop too many references
We only have one reference to the surface,
and it is dropped by gdk_surface_destroy.
All the users of surfaces in gtk had the same
bug: they were all stealing an extra reference
to drop - the one that the renderer was leaking
until recently.
Matthias Clasen [Wed, 10 May 2023 11:34:23 +0000 (07:34 -0400)]
gsk: Dispose the driver when the display is closed
This was the intention, but the object data by itself
does not achieve that: We do run dispose on the display
when it is closed, but object data is only cleared in
finalize. So listen to the ::closed signal and remove
the driver ourselves.
Fix up the drivers dispose implementation enough for
that to actually work.
Emmanuele Bassi [Tue, 9 May 2023 16:02:09 +0000 (17:02 +0100)]
Minimize the amount of inclusions in public headers
Public headers should mainly include gdktypes.h, which already include
the symbol visibility and versioning macros; we can also modify
gdktypes.h to include the enumerations.
Emmanuele Bassi [Tue, 9 May 2023 14:31:27 +0000 (15:31 +0100)]
demos: Drop symbol visibility macros from demo types
Since the corresponding source files do not include "config.h", and are
not compiled with `GTK_COMPILATION`, they will generate the wrong symbol
exporting under Windows.
Benjamin Otte [Fri, 18 Feb 2022 02:21:48 +0000 (03:21 +0100)]
sortlistmodel: Implement GtkSectionModel
The get_section() implementation is a slow and steady implementation
that has to be careful to not screw up when an incremental sort is only
partially sorted.
Benjamin Otte [Tue, 9 May 2023 12:41:24 +0000 (14:41 +0200)]
wayland: Don't assert when requesting another frame
When GDK_DEBUG=no-vsync is on, we might have more than one outstanding
frame. Don't assert when that hapens. Just request a frame callback for
the first and skip the others.
Benjamin Otte [Tue, 9 May 2023 12:38:24 +0000 (14:38 +0200)]
frameclock: Keep more history
Not all frames get timing info with GDK_DEBUG=no-vsync, so make sure
that even when we render tons of frames, the one frame that does get
timing info is still there when the timing info arrives.
I set it to 128 from 16 now.
This is roughly good enough to go to 5000fps from on a 60Hz monitor.
...when we are using wglChoosePixelFormatARHB(). This ensures that we
hvae a HDC with a pixel format that will really support alpha bits, as
we did for the traditional ChoosePixelFormat().
Thanks to Patrick Zacharias for testing and pointing things out.
Chun-wei Fan [Thu, 4 May 2023 16:09:43 +0000 (00:09 +0800)]
GDK/Win32: Use dummy WGL contexts more
... for creating the actual WGL contexts, so that we can cut down on the
number of times where we need to create the base, legacy WGL contexts in
order to create the WGL contexts with attributes. We could just use the
dummy context that we have to make it current to create the needed
WGL contexts.
Chun-wei Fan [Wed, 3 May 2023 09:58:54 +0000 (17:58 +0800)]
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB()
If we are querying the best supported pixel format for our HDC via
wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension),
it may return a pixel format that is different from the pixel format that we
used for the dummy context that we have setup, in order to, well, run
wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be
current in order to use it, which means the dummy HDC already has a pixel
format that has been set (notice that each HDC is only allowed to have its
pixel format to be set *once*). This is notably the case on Intel display
drivers.
Since we are emulating surfaceless GL contexts, we are using the dummy GL
context (and thus dummy HDC that is derived from the notification HWND used in
GdkWin32Display) for doing that, we would get into trouble if th actual HDC
from the GdkWin32Surface has a different pixel format set.
So, as a result, in order to fix this situation, we do the following:
* Create yet another dummy HWND in order to grab the HDC to query for the
capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as
appropriate (or ChoosePixelFormat()) for the final pixel format that we use.
* Ditch the dummy GL context, HDC and HWND after obtaining the pixel format.
* Then set the final pixel format that we obtained onto the HDC that is derived
from the HWND used in GdkWin32Display for notifications, which will become our
new dummy HDC.
* Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless
GL support.
Chun-wei Fan [Mon, 8 May 2023 02:59:51 +0000 (10:59 +0800)]
gdkglcontext-win32-wgl.c: Fix WGL context realization on 32-bit
We are currently using g_clear_pointer() on the intermediate WGL contexts
(HGLRC)'s that we need to create in the way, which means that we need to ensure
that the correct calling convention for wglDeleteContext() is being applied.
To be absolutely safe about it, use the gdk_win32_private_wglDeleteContext()
calls, which will in turn call wglDeleteContext() directly from opengl32.dll
(using the OpenGL headers from the Windows SDK) instead of going via libepoxy,
which will assure us that the correct calling convention is applied.
Matthias Clasen [Mon, 8 May 2023 01:26:09 +0000 (21:26 -0400)]
Introduce GTK_ALIGN_BASELINE_FILL/CENTER
It turns out that the old behavior of GTK_ALIGN_BASELINE
was actually used in libadwaita, so bring it back, and
introduce a new GtkAlign value for the new behavior.